@Hexiaoqiao @MingXiangLi @ZanderXu please help me review the code.

DataSetLockManager only print lock trace when invoke DataNode.shutdown() or dataSetLockManager.lockLeakCheck().So I doubt it will work in all UT.

Ans should we throw Exception ? Most of user will ignore if just print the log.

DataSetLockManager only print lock trace when invoke DataNode.shutdown() or dataSetLockManager.lockLeakCheck().So I doubt it will work in all UT.

Thanks for the suggestion, I think this parameter can cover scenarios like HDFS-16600, DN shutdown will definitely be called in Junit Test, I personally feel that if there is an error in the junit test of DN and if we suspect a deadlock, we can see this print message.

Ans should we throw Exception ? Most of user will ignore if just print the log.

If a thread obtains a read lock (write lock) and needs to obtain a write lock (read lock), will an exception be thrown directly?
My understanding is that once a deadlock occurs, the code will definitely report an error, and there is no need to throw an exception directly. I personally feel that printing is enough. of course, we can also throw exceptions directly.

🎊 +1 overall

This message was automatically generated.

@slfan1989 It's a good idea. But I personally feel that it would be nice to thrown exception directly in the test environment when there is a lock leak.

@MingXiangLi @ZanderXu @Hexiaoqiao Thanks for helping to review the code, can I make the following changes?

public void lockLeakCheck() throws Exception {
    if (!openLockTrace) {
      LOG.warn("not open lock leak check func");
      return;
    }
    if (threadCountMap.isEmpty()) {
      LOG.warn("all lock has release");
      return;
    }
    setLastException(new Exception("lock Leak"));
    threadCountMap.forEach((name, trackLog) -> trackLog.showLockMessage());
    // throw exception ?
    throw new Exception("lock Leak");
  }

From my side, I do not think enable lock trace only is good idea for tests as @MingXiangLi has mentioned above. The only INFO level log will not help to debug or test. IMO, if there are some cases we would like to cover and need to collect locks information, it is better to add some inject logic. FYI.

From my side, I do not think enable lock trace only is good idea for tests as @MingXiangLi has mentioned above. The only INFO level log will not help to debug or test. IMO, if there are some cases we would like to cover and need to collect locks information, it is better to add some inject logic. FYI.

Thank you very much for your suggestion, I will think about how to collect lock information!

🎊 +1 overall

This message was automatically generated.

🎊 +1 overall

This message was automatically generated.

readLock

getVolume(final ExtendedBlock b)
getStoredBlock(String bpid, long blkid)
Set<? extends Replica> deepCopyReplica(String bpid)
getBlockInputStream(ExtendedBlock b, long seekOffset)
moveBlockAcrossStorage(ExtendedBlock block, StorageType targetStorageType, String targetStorageId)
moveBlockAcrossVolumes(ExtendedBlock block, FsVolumeSpi destination)
ReplicaHandler createRbw(StorageType storageType, String storageId, ExtendedBlock b, boolean allowLazyPersist)
Map<DatanodeStorage, BlockListAsLongs> getBlockReports(String bpid)
public List<ReplicaInfo> getFinalizedBlocks(String bpid)
public boolean contains(final ExtendedBlock block)
public String getReplicaString(String bpid, long blockId)
public long getReplicaVisibleLength(final ExtendedBlock block)
public BlockLocalPathInfo getBlockLocalPathInfo(ExtendedBlock block)

🎊 +1 overall

This message was automatically generated.